AMENDMENTS TO THE SPECIFICATION 



Please amend page 1, four paragraphs beginning on In. 10 as follows: 

This application relates to application serial no. — 09/884,179 (attorney docket 

M 10956 US) , filed on June 18, 2001, entitled "Rules Based Provision of Custom Pricing for 
Multiple Entities" and naming Scott Bonneau, Michael Nonemacher and Jeremy Weinrib as 
inventors, now pending, the application being incorporated herein by reference in its entirety. 

This apphcation relates to application serial no. — 09/884,216 (attorney docket M 

10957 US) , filed on June 18, 2001, entitled "Rules Based Custom Catalogs Generated from a 
Central Catalog Database for Multiple Entities" and naming Scott Bonneau, Michael 
Nonemacher and Jeremy Weinrib as inventors now U.S. Patent No. 6,978,273, issued 12/20/05 , 
the application being incorporated herein by reference in its entirety. 

This apphcation relates to application serial no. — 09/884,180 (attorney docket M 

10958 US) , filed on June 18, 2001, entitled "Logical and Constraint Based Browse Hierarchy 
with Propagation Features" and naming Scott Bonneau, Michael Nonemacher and Jeremy 
Weinrib as inventors, now U.S. Patent No. 6,834,282, issued 12/21/04 , the application being 
incorporated herein by reference in its entirety. 

This apphcation relates to application serial no. — 09/886,691 (attorney docket 

M 10959 US) , filed on June 18, 2001, entitled "Rules Based Provision of Custom Pricing for 

Multiple Entities" and naming Scott Bonneau and Michael Nonemacher as inventors, abandoned, 

the application being incorporated herein by reference in its entirety. 

Please replace the paragraph on page 14, lines 15-23 with the following amended 
paragraph: 

Fig. 2 illustrates that customized versions of the seller's catalog data can be provided to 
buyers using the present invention in different modes, depending upon the type of buyer. One 
mode of providing customized versions of seller's catalog is employed for an extranet 
relationship between the seller and certain buyers. An extranet is simply a business-to-business 
link between the seller and one or more buyers using the Internet 40. In this case, extranet web 
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server 12 couples buyer-authorized and seller-authorized users to the application server 8 over 
the Internet 40 through terminals 36 and 38 respectively. Thus, buyer-authorized users can 
access and browse the seller's catalog data directly using a computer such as a personal 
computer (PC) terminal 36 running a web browser. 

Please replace the paragraph on page 15, lines 8-18 with the following amended 
paragraph: 

For one extranet embodiment, seller-authorized users can perform catalog database rule 
set and primary hierarchy creation and maintenance either over the Internet 40 using a machine 
such as a PC running a web browser [[38]], or directly through the application server 8 as 
previously discussed. Both the seller and the buyer(s) authorize users to access the application 
running on application server 8, which is accomplished through extranet web server 12 coupled 
to browsers [[14]] 36 and 38 over the Internet 40. Those of skill in the art will recognize that a 
single server could be used to run both the application as well as the web server application. 
Because the buyer has direct access to the database 10 through extranet web server 12 and 
application server 8, updates to the virtual custom catalogs and custom browse hierarchies for the 
extranet buyers are available to every extranet buyer immediately upon completion of the 
publication process. 

Please replace the paragraph on page 15, lines 26-31 with the following amended 
paragraph: 

A second possible context for which exportation is applicable is a public marketplace, 
whereby two or more buyers establish a proprietary web site with web server 16 , through which 
they offer items including some of the seller's items. As in the previous example, proprietors of 
the public marketplace may wish to incorporate some subset of seller's items with some into its 
catalog. Customers of the public marketplace web site access the custom catalog information 
through browsers 18 over the Internet 40. 

Please replace the paragraph on page 16, lines 1-5 with the following amended 
paragraph: 
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Another context in which exportation of customized catalog and pricing is applicable is 
when a seller wishes to offer some customized subset of its catalog to the many potential 
purchasers that belong to a private procurement nctworlc networks 20. Member buyers and 
sellers are authorized to access the procurement notworlc networks , either directly using 
terminals 17, or indirectly through Internet 40 using browser 15. 

Please replace the paragraph beginning on page 16, line 25 - page 17, line 2 with the 
following amended paragraph: 

The fact that the customized catalog for a particular buyer is a subset of the items 
contained in the full catalog database 10 and that the custom browse hierarchy is pared down to 
have a scope that is coextensive with that subset of items is completely transparent to the buyers 
in both the extranet and non-extranet contexts. In both cases, the seller maintains the primary 
single database 2 4 catalog database 10 and the primary hierarchy. In both cases customized 
versions of the catalog and browse hierarchy are generated during the virtual publication process. 
The only difference is that they are provided in real-time to the various extranet buyers, while 
physical manifestations of the customized versions of the catalog and browse hierarchy must be 
exported to external buyers. 

Please replace the paragraph on page 17, lines 3-15 with the following amended 
paragraph: 

Fig. 3 illustrates one extranet embodiment of the invention. A database server 9 provides 
access to catalog database 10. The database server 30 receives queries from application/ web 
server 34 over bus 32 using an appropriate communication and database protocol such as TCP/IP 
and JDBC/ADO respectively. As previously discussed, the application of the present invention 
and the web server application can be run on the same machine 34. Seller-authorized users can 
maintain and update the catalog database 10 and the primary hierarchy, and create new extranet 
accounts with buyers using terminals 38. The seller-authorized users can access the application 
directly or over the Internet 40 through the web server application. New catalog data can be 
imported into database 10 from manufacturers, suppliers, etc. over XML import input [[33]] 24. 
An example of an import file formatted in XML is attached hereto as Appendix A. The 
application/web server 34 typically runs an operating system such as Windows NT 4/IIS, 
available from Microsoft Corporation, or some version of Unix. 
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Please replace the paragraph on page 17, lines 27- page 18, Une 8 with the following 
amended paragraph: 

Buyer-authorized users begin the process by accessing the database 10 using web 
browsers terminals 36. The users typically connect to the Internet 40 first through their Internet 
Service Provider (ISP) and then contact server 34 by entering the extranet URL to the browser. 
The web server application running on server 34 communicates with the application running on 
server 34 and returns an authorization web page that requests buyer authorization information 
and the buyer's rule set identifier. The user responds and the information is communicated to the 
server 34. The application verifies the information. If the user is authorized, the application 
communicates the correct custom browser hierarchy, based on the buyer's assigned rule set 
identifier, in the form of web pages for display on browser terminal 36. Catalog inquires are 
then generated either directly as a rules based search submitted by the user, or by browsing the 
hierarchy and selecting one of the leaf nodes. They are communicated by the browser to the web 
server, which passes them on to the application for conversion to a database query. 

Please replace the paragraph on page 21, lines 1-12 with the following amended 
paragraph: 

The format illustrated in Fig. 5a is designed to facilitate the creation and maintenance of 
the catalog data. However, it is not optimal for searching for items having certain attribute 
values (VAL) . Thus, as illustrated by step 52 of Fig. [[5a]] 4a, upon commencement of virtual 
publication (i.e. when new and/or updated custom catalogs are to be generated), the catalog 
database is locked and the data is converted to the format illustrated in Fig. 5b. A table is created 
for each product type, and each table comprises just one row per SKU, and a column for each 
attribute belonging to the product type. The tables of Fig. 5b include some additional item SKUs 
not shown in Fig. 5a to illustrate that other items can fall under the product type, and that each 
item SKU has a unique combination of the attribute/ value (att/val) pairs. The advantage to the 
converted format is that when searches are performed on the data, the amount of data to be 
searched [[can]] is pared down first based on product type, and then by attribute/value pairs. 
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Please replace the paragraph on page 23, lines 18-27 with the following amended 
paragraph: 

Once all extranet rules set searches have been completed, the subset table contains a set 
of SKU entries for each rule set, with each of the set of SKU entries identified by its 
corresponding rule set identifier. The set of SKUs for each rule set makes up the subset of the 
catalog database items comprising a custom catalog, the scope of which is defined by the specific 
rule set used to generate it. Processing then continues at step 57 (Fig. 4a), at which point a 
custom browse hierarchy is generated for each rule set having a scope which is coextensive with 
the scope of the subset of items defined by each rule set. A more detailed description of one 
embodiment of the process flow by which a custom browse hierarchy is generated in step 57 for 
a particular rule set is illustrated by Figs. 1c and Id Fig. 4c . This process is performed for each 
rule set assigned to an extranet buyer or buyer group. 

Please replace the paragraph on page 23, lines 28- page 24, line 5 with the following 
amended paragraph: 

Referring to Figs. 4c and 7, processing Processing continues at step 570 (Fig. 1c) wherein 
a first unprocessed leaf node is located in the primary hierarchy based on a depth- first-search. 
With respect to the hierarchy in Fig. 7, this first step will identify node 152 as the first 
unprocessed leaf node. Processing then continues at decision step 574, where it is determined 
whether there are any unprocessed leaf nodes that were located under step 570. If an 
unprocessed leaf node was located, then processing continues at processing step 572. Otherwise 
processing continues at step 576 where the application begins building custom hierarchies for 
each rule set. Given that node 152 of the hierarchy example of Fig. 7 has been located as 
unprocessed, processing continues at processing step 572. 

Please replace the paragraph on page 24, lines 28- page 25, line 9 with the following 
amended paragraph: 

Once all leaf nodes have been processed as previously described, processing continues at 
step 576 (Fig. 1c) where a custom hierarchy is generated for each custom catalog subset as 
represented by each rule set ID. A more detailed description of the process step 576 for 
generating custom hierarchies is illustrated in Fig. 4d. Processing continues at step 700 at which 
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time the primary hierarchy is again walked in a depth first search, this time to determined the 
left-most leaf node that has not been cloned or deleted. As applied to the example hierarchy of 
Fig. 7, this will again start out with the identification of node 152. At processing decision step 
702, it is determined whether the rule set ID associated with the custom catalog subset for which 
a custom hierarchy is currently being generated exists in the cached set for leaf node 152. If it 
does exist in the cached set, processing continues at step 716 where leaf node 152 is cloned as 
part of the custom browse hierarchy being generated. Processing then continues at 718 the 
process retreats one level to the parent node of leaf node 152 which is the next ancestor of 152, 
and this node is marked "to be cloned." 

Please replace the paragraph on page 25, lines 10-25 with the following amended 
paragraph: 

Processing continues at decision step 706 through intersection node 720 where it is 
determined whether the ancestor node 151 has any unprocessed children. In this case the answer 
is "yes," and processing resumes again at step 700 where the next left-most leaf is identified 
which, in our example, would be node 153. Processing continues again at decision step 702 to 
determine whether the rule set ID for the custom catalog subset for which a custom hierarchy is 
currently being generated and is contained in the cabled set for leaf node 153. If the subset ID 
does currently exist in the cache set for leaf node 145, processing continues as previously 
described at processing step 716 and beyond. If the subset ID is not included in the cached set 
for leaf node 153, processing continues at step 704 where leaf node 153 is not cloned and 
included in the custom browse hierarchy currently being generated. Processing then continues at 
decision step 706 where the process takes a step up in the hierarchy to the first ancestor of leaf 
node 153 where it is determined whether node 151 has any other unprocessed children. If the 
answer is yes, processing continues at step 700 as previously described. In our example primary 
hierarchy of figure Fig. 7, ancestor node 151 has no additional unprocessed children and therefore 
the answer to decision step 706 would be "No." 
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Please replace the paragraph on page 26, lines 3-8 with the following amended 
paragraph: 

Processing would then continue at step 714 where the process takes another step back up 
in the hierarchy to the next ancestor node of node 151. In our example, this node would be node 
145. Processing then continues through intersection node 720 at processing step 706 where it is 
determined whether the ancestor node 145 has any unprocessed children. In our example, the 
answer to this question is "Yes" because node 148 has not yet been processed. Therefore, 
processing continues at step 700 and beyond for leaf nodes 149, 150, 144, etc. as previously 
described. 

Please replace the paragraph on page 26, lines 9-18 with the following amended 
paragraph: 

Returning back to processing step 708, had the answer to the question posed been "No" 
rather than "Yes," ancestor node 151 would have been deleted in step 722 because it would not 
have had any children which were cloned underneath it and therefore the ancestor node would 
not be necessary either. Processing then continues at decision step 724 where it is determined if 
the ancestor that was just deleted is the root of the hierarchy. If the answer is "Yes," the process 
ends in step 728 for this custom browse hierarchy and a custom browse hierarchy is then 
generated for any remaining rule sets for which one has not yet been generated. If the answer is 
"No," processing continues at step 726 where the process takes a step back up in the hierarchy to 
the next ancestor node 143 and then processing continues at decision step 706 through 
intersection node 720 and processing proceeds as previously described. 

Please replace the paragraph on page 26, beginning on line 25- page 27, line 4 with 
the following amended paragraph: 

Once all the custom browse hierarchies have been generated for each rule set, the virtual 
publishing process has been completed for extranet buyers. The system is now prepared to 
receive requests from users authorized by buyers to access the catalog database through their 
respective extranets and respond to catalog inquiries initiated by extranet buyers at step 58, 
which is illustrated in more detail in Fig. 4e . As previously described, this process typically 
involves the user accessing the internet through their internet service provider (ISP) and sending 
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the request using a browser program to the seller's web server. The request typically includes the 
rule set identifier assigned to the buyer as well as some sort of authorization number that 
identifies the particular buyer. This step is illustrated in Fig. 4e at step 580. Typically, the 
validation process will involve a password to permit only those authorized by the buyer to access 
the catalog database. 

Please replace the paragraph on page 27, lines 5-25 with the following amended 
paragraph: 

Once the user has been authorized, the next step in the process is illustrated by processing 
step 582 at which time the application provides the appropriate customized browse hierarchy 
associated with the rule set identifier assigned to the buyer which is then provided to the buyer's 
browser over the internet as a set of web pages as transmitted by the seller's web server for 
display on the buyer-authorized user's browser terminal. Processing then continues at step 584 
where catalog inquiries may be generated by the buyer-authorized user. These inquiries being 
generated by the browser, transmitted over the internet, and received by the seller's web server. 
Buyer catalog inquiries can be generated in one of two ways. The first is by browsing the 
customized browse hierarchy currently displayed on the user's terminal. Typically, selecting a 
leaf node will cause the aggregation of all constraints contained in any of the nodes in the path 
browsed by the user and a rule based catalog inquiry will be generated based on that aggregation 
of constraints and transmitted to the seller's web server over the internet and then passed from 
there to the seller's application server. The apphcation server then converts the rules based 
catalog inquiry into a database query which is used to search the catalog database and return a set 
of SKUs that meet the aggregated constraints. [[This]] In step 586, this set of SKUs is then 
joined to the subset ID table and only those SKUs that have entries in the subset ID table [[the]] 
that are associated with the buyer's assigned rule set identifier will ultimately be returned back to 
the user by way of the internet. In step 588, all descriptive information for each retained SKU is 
provided a Web page to a browser of a buyer. The information that is returned to the user may 
include a hst of SKUs, item attributes, and associated image and marketing text that the seller 
may wish to display in conjunction with the returned set of SKUs. 
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Please replace the paragraph on page 28, lines 5-12 with the following amended 
paragraph: 

Referring back to Fig. 4a and decision step 54 of Fig. 1e , if non-extranet buyers have also 
been identified, processing for those buyers proceeds at step 60. At step 60, searches are run on 
the catalog database for all of the rule sets assigned to non-extranet buyers in virtually the same 
manner as at step 56. One difference is that separate catalog subset tables are created for each of 
the rule sets assigned to non-extranet buyers. Processing then continues at step 62, where 
catalog data, including all descriptive information associated with each item SKU, is extracted 
from the catalog database for all SKUs in each catalog subset table. In essence, a complete copy 
of the catalog subset is created for each rule set assigned to a non-extranet buyer. This must be 
done because, unlike the extranet buyer, the non-extranet buyers are not directly coupled to the 
catalog database. 
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